What the issue is

The test 'delivered to peer with no handler -> no error thrown on sender' does:

const [client, server] = await linkedPair();
const errors: Error[] = [];
client.onerror = e => errors.push(e);
await expect(server.sendCustomNotification('acme/unhandled', { x: 1 })).resolves.toBeUndefined();

The errors array and client.onerror hook are set up but never read. The only assertion is that server.sendCustomNotification(...) resolves to undefined. The error-capture lines contribute nothing to the test outcome.

Why it's slightly confusing rather than purely harmless

The test name says "no error thrown on sender". The sender here is server; the .resolves.toBeUndefined() already fully covers that claim. The onerror hook is attached to client — the receiver — so even if it were asserted on, it would be testing a different property ("receiver doesn't surface an error for an unhandled custom notification") than the one named. A reader skimming the test sees error-capture setup and reasonably assumes it's load-bearing, then has to trace through to discover it isn't.

Why existing code doesn't catch it

Vitest doesn't warn on unused locals, and the test passes because the only real assertion (resolves.toBeUndefined()) is correct. Lint won't flag errors since it's written to inside the closure.

Addressing the "too minor" objection

One reviewer noted this is harmless dead scaffolding and not worth flagging. That's fair on impact — it doesn't affect production code or test correctness. But this is brand-new test code being added in this PR (not pre-existing), and the fix is deleting two lines (or adding one assertion). Cleaning it up before merge is essentially free and avoids leaving a misleading setup in a file that will be the reference for future custom-method tests. Filed as a nit accordingly — not blocking.

How to fix

Either delete the two setup lines:

test('delivered to peer with no handler -> no error thrown on sender', async () => {
    const [, server] = await linkedPair();
    await expect(server.sendCustomNotification('acme/unhandled', { x: 1 })).resolves.toBeUndefined();
});

or, if the receiver-side quiet is also intended to be covered, assert it and adjust the test name:

await new Promise(r => setTimeout(r, 0));
expect(errors).toEqual([]);

Step-by-step proof

1. Test creates linked pair; server is sender, client is receiver.
2. errors array allocated; client.onerror set to push into it.
3. server.sendCustomNotification('acme/unhandled', {x:1}) called → routes through notification() → transport send → resolves undefined.
4. .resolves.toBeUndefined() passes — this is the only assertion.
5. On the client side, _onnotification finds no handler for 'acme/unhandled' and returns early (protocol.ts _onnotification: "Ignore notifications not being subscribed to"), so client.onerror never fires and errors stays [].
6. Test ends. errors is never read. Deleting lines 234–235 produces an identical pass/fail outcome.

What the issue is

The two new example files introduced in this PR — examples/server/src/customMethodExample.ts:19 and examples/client/src/customMethodExample.ts:13 — import zod via import { z } from 'zod'. Every other example file in the repository (9 files total: simpleStreamableHttp.ts, mcpServerOutputSchema.ts, etc.) and the SDK internals use import * as z from 'zod/v4'. CLAUDE.md §Zod Schemas explicitly states "The SDK uses zod/v4 internally", and docs/migration.md shows import * as z from 'zod/v4' in its v2 examples.

Why it matters (mildly)

The bare 'zod' specifier and the 'zod/v4' subpath are not guaranteed to resolve identically. Zod 4.x ships both entry points and they currently re-export the same module, so this works fine at runtime in this repo. However, in a downstream project that has both zod v3 and v4 installed (e.g. via transitive deps), the bare 'zod' specifier may resolve to v3 while 'zod/v4' pins to v4. Since these are example files that users copy-paste, propagating an inconsistent import style undermines the convention the rest of the codebase establishes.

Why this isn't a functional bug

This is purely a consistency/style issue in example code. The repo's own zod dependency is v4, so both import forms resolve to the same module here, and the examples build and run correctly. No SDK behavior is affected.

How to fix

Change line 19 of examples/server/src/customMethodExample.ts and line 13 of examples/client/src/customMethodExample.ts from:

import { z } from 'zod';

to:

import * as z from 'zod/v4';

Step-by-step proof

1. grep -rn "from 'zod" examples/ shows 11 zod imports across the examples directory.
2. 9 of them (all pre-existing files) use import * as z from 'zod/v4'.
3. The 2 new files in this PR are the only ones using import { z } from 'zod'.
4. grep -rn "from 'zod'" packages/ shows zero matches in SDK source — internals exclusively use 'zod/v4' (e.g. packages/core/src/types/schemas.ts:1, packages/core/src/util/schema.ts:6).
5. Therefore the two new files are the sole deviation from an otherwise repo-wide convention.